Stamps Without Passports: Identity with Agentic Systems

In 1921, the Soviet government revoked citizenship for all Russians living abroad. Overnight, roughly 800,000 refugees became stateless. They could not cross borders. They had no identity document any country recognized. Individual nations issued them entry permits and work authorizations, credentials for specific purposes in specific jurisdictions. No foundational document bound those credentials together. A refugee with a French work permit and a German entry visa had two stamps and no passport. In 1922, the Norwegian diplomat and polar explorer Fridtjof Nansen convened a conference in Geneva and created the Nansen passport, the first internationally recognized identity document for stateless people. Governments issued approximately 450,000 Nansen passports across 52 countries. Marc Chagall, Igor Stravinsky, and Anna Pavlova carried one. The passport did not grant citizenship. It established a foundational identity that made every other credential meaningful.

AI agents are the stateless refugees of the identity system. They carry API keys for specific services, OAuth tokens for specific scopes, and service account credentials for specific environments. No foundational identity binds these credentials together, traces delegation back to a responsible human, or enables governance across the agent’s full operational scope. Machine identities outnumber human identities 82 to 1 in enterprise environments. In some sectors, the ratio approaches 500 to 1. The identity infrastructure built for the 1-in-82 is now responsible for the other 81, and it was not designed for stochastic actors that delegate, reason, and decide at runtime which tools to call.

In The Linguistic Von Neumann Bottleneck, I argued that agents need their own cryptographic identities. This post defines what that identity must be, why existing identity models fail to provide it, and where the standards landscape stands today.

The wrong credentials #

When teams build agent systems, they reach for the identity models they already have. Each one fails for a different reason, and the failures trace back to the same root cause: agents are not the entities these models were designed for.

The first instinct is credential inheritance. The agent runs with the user’s OAuth token or AWS role. This gives the agent the user’s full authority with none of the user’s judgment. In 1988, Norm Hardy described the confused deputy: a compiler at Tymshare had legitimate file access and was tricked into writing its output to the system billing file, destroying the billing data. The compiler had authority. An attacker directed how that authority was used. Hardy’s insight was that the problem was structural, not behavioral. The compiler was not buggy. It was confused, a legitimate deputy wielding legitimate permissions on behalf of the wrong principal. AI agents are the modern confused deputy. As I described in The Linguistic Von Neumann Bottleneck, prompt injection can direct an agent to misuse the permissions it legitimately holds. The user is not present to intervene. The delegation happened when the user launched the agent. The exploitation happens after the user walks away. And in the audit log, the agent’s actions are indistinguishable from the user’s own, because they share the same identity.

The second instinct is a service account, a static credential with a fixed scope. Service accounts work for deterministic software. A web server needs access to port 443 and a database connection. Those permissions do not change at runtime. An agent decides at runtime which tools to call, what data to access, and when to escalate. A service account for a customer support agent either grants access to all customer records, too broad for most tasks, or only the records relevant to the current request, impossible to predict when the credential is issued. Static scope cannot match dynamic behavior. Service accounts are also long-lived. They persist after the agent is destroyed, creating dangling credentials with no expiration, no delegation chain, and no way to trace the authority back to the human who initiated the workflow.

The third instinct is workload identity. SPIFFE (Secure Production Identity Framework for Everyone) gives workloads cryptographic identity based on what they are and where they run. A SPIFFE Verifiable Identity Document proves “this is workload X running in environment Y,” and it is short-lived, typically one hour. This addresses the lifecycle problem and the cross-boundary problem. But SPIFFE does not carry delegation semantics. It proves identity without proving authority. A SPIFFE SVID does not say “this workload is acting on behalf of user Z with scope limited to read:orders for the next fifteen minutes.” It says “this workload exists.” That is necessary but not sufficient. The agent needs to prove not just what it is, but who authorized it, for what purpose, and with what constraints.

Each of these models solves a real problem for the entity it was designed for. Users need delegated access. Services need static credentials. Workloads need attestation. Agents need all three simultaneously, and no single model provides the composition.

What agents require #

To define what agent identity must be, start with what agents are. Agents differ from users and services in five ways that matter for identity.

Their behavior is stochastic. A user clicks a button and the system executes a predictable code path. An agent receives a prompt and decides at runtime which tools to call, what data to access, and when to escalate. You cannot pre-authorize a fixed set of actions because you cannot predict what the actions will be. The identity system must support dynamic, per-task scoping.

Agents delegate without presence. The user launches the agent and walks away. The agent continues to act on the user’s behalf without the user approving each action. The identity must carry proof of delegation that persists after the delegator is gone, cryptographically binding the agent’s actions to the human who authorized them.

Agents delegate to other agents. Agent A delegates to Agent B, which delegates to Agent C. Each hop must narrow scope, never broaden it, a property called scope attenuation. An agent that discovers it needs elevated permissions must request a new credential through the delegation chain, not expand the existing one. The escalation path exists, but it runs through the identity system, not around it. The identity must carry the full delegation chain so that any verifier can trace the authority back to the original human.

Agents are ephemeral. An agent might exist for fifteen minutes to complete a task, then be destroyed. Traditional identity systems manage entities that persist for months or years. Agent identity must support rapid provisioning and deprovisioning without the overhead of traditional lifecycle management.

Agents operate across trust boundaries. A single task might require interaction with an internal database, a third-party API, a payment network, and another organization’s agent. The identity must be verifiable across all of these without requiring every verifier to call back to a central authority.

These five properties drive six requirements for agent identity:

Agent identity is the cryptographic answer to three questions: what acted, on whose behalf, and with what authority. It must be verifiable across trust boundaries without callback, carry the full delegation chain from the original human through every agent that participated, attenuate scope at each hop, expire on a timeline measured in minutes, and bind to the specific task the agent is performing. In The Linguistic Von Neumann Bottleneck, I showed what this looks like as a JWT with sub, act, and scope claims. Here is a concrete example of a delegation chain with scope attenuation across two hops:

{
  "iss": "https://identity.example.com",
  "sub": "user:jchen@example.com",
  "aud": "https://api.inventory.example.com",
  "exp": 1711540200,
  "iat": 1711539300,
  "scope": "inventory:read:sku-8842",
  "act": {
    "sub": "agent:order-processor-7f3a",
    "act": {
      "sub": "agent:customer-support-a1b2"
    }
  }
}

The sub claim identifies the human on whose behalf the token acts: jchen. The outermost act identifies the current actor: the order-processor agent. The nested act records the prior actor: the customer-support agent that delegated to the order-processor. This follows the RFC 8693 delegation model, where sub is always the original subject and act chains trace the delegation history. The scope claim at the top level constrains what the current actor can do: read access to a single SKU. Scope attenuation happens at each token exchange. The customer-support agent held orders:read customer:read inventory:read. When it delegated to the order-processor, the authorization server issued a new token with narrower scope: inventory:read:sku-8842. The token expires in fifteen minutes. Any verifier can validate this token, reconstruct the full delegation chain, and confirm that the requested scope falls within the attenuated permissions, without calling back to a central authority.

Passports under construction #

The definition above is not theoretical. The IETF has at least six active drafts addressing agent identity, and in February 2026, NIST published a concept paper asking the industry how to apply identity standards to AI agents. The standards community recognizes the gap. The question is whether the standards arrive complete.

The IETF’s starting position is correct: agents are workloads. The WIMSE working group (Workload Identity in Multi-Service Environments) extends its workload identity framework to AI agents, giving them cryptographic attestation through SPIFFE. This addresses two of the six requirements: cryptographically verifiable and attestable. It does not address delegation, scope attenuation, or per-task scoping. Knowing what the agent is and where it runs is necessary. Knowing who authorized it and what it should be allowed to do is the harder problem.

The most ambitious composition attempt is AIMS (Agent Identity Management System), a 26-page framework that composes WIMSE, SPIFFE, and OAuth 2.0 into a unified authentication model. AIMS adds delegation semantics through OAuth token exchange, a protocol that lets one party swap an existing token for a new token with different scope and audience, and multi-hop context through transaction tokens, short-lived tokens that carry context about the original request across multiple services in a call chain. AIMS builds on existing primitives rather than inventing new ones, which reduces adoption friction but leaves the authorization gap unaddressed. As one analysis of the draft observed: authentication gets the hard part right. Authorization is still your problem. AIMS proves who the agent is and who authorized it. It does not decide what the agent can do right now, for this specific task, given the current context. That decision is explicitly out of scope.

A reasonable objection: this is not a new identity category. It is a composition problem. SPIFFE provides attestation. OAuth token exchange provides delegation. Transaction tokens provide multi-hop context. Cedar and OPA/Rego provide authorization. Compose them and you solve the problem. The objection is half right. The primitives exist. The composition standard does not. Today, composing these primitives requires custom integration at every trust boundary. Each organization makes different choices about which primitives to combine and how to wire them together. Agent A’s identity token is not verifiable by Agent B’s policy engine without bilateral agreement. The primitives are not the gap. The interoperable composition is.

The remaining gap is authorization. Identity answers “who are you?” Authentication proves the answer is genuine. Authorization answers “what can you do right now?” For agents, that answer must be dynamic (per-task), contextual (based on what the agent has already done in this session), and enforceable outside the model’s reasoning loop, where prompt injection cannot reach it. No IETF draft addresses this. The standards community is solving authentication. No one is standardizing authorization. Cedar and OPA fill this gap today as implementation choices, evaluating structured authorization requests against deterministic logic. But they operate outside the identity standard. Until authorization is composed into the same framework as authentication and attestation, agent identity solves half the problem: it proves who the agent is without constraining what the agent can do.

The tradeoff #

Agent identity infrastructure is not free. The standards are drafts, not deployed specifications. Building on them means accepting the risk that mechanisms change before they stabilize. The cold start problem is real: you need identity infrastructure before you deploy your first agent, but the return is not visible until you operate many agents across trust boundaries.

Not every agent needs the full delegation chain. An agent that summarizes a document in a sandbox with no access to sensitive data and no external communication can operate with a scoped service account. The identity requirements scale with the agent’s operational scope. As I argued in Weighting the Switch, match the control to the risk. A Tier 1 agent with local, read-only, reversible operations needs minimal identity. A Tier 3 agent that crosses trust boundaries, delegates to other agents, and accesses sensitive data needs the full delegation chain, scope attenuation, and attestation. Start with the risk. Match the identity to the risk.

Brooker argues in Agent Safety is a Box that the deterministic boundary around the agent is the foundation. The box isolates. The gateway enforces. He is right. Identity is not the foundation. It is the first thing you build on that foundation. The box’s policy engine needs a principal to evaluate. The gateway needs a credential to verify. The audit log needs an actor to attribute. The revocation system needs a credential to revoke. Without identity, the box is a locked room with no way to decide who gets a key.

Upcoming posts will address the authorization layer that identity enables: formal policy composition for multi-agent delegation chains, and the deployment patterns where the absence of agent identity creates a direct path from untrusted input to sensitive data to the outside world. The box comes first. Identity is what makes the box useful. You cannot authorize what you cannot identify. You cannot audit what you cannot attribute. You cannot revoke what you cannot name.

Thanks for reading Probably Secure. Let’s get to work. Always be curious…all opinions are my own.